先把設計目標寫下來

開始動手前，我給自己留了一段時間，先把「設計目標」想清楚，我的目標使用者＆期望達到的目標。

這個工具要做什麼：幫需求方PM 可以把需求想＆寫清楚。

設計目標決定的不是「做什麼」，是做完之後，怎麼判斷做出來的東西夠不夠好。

如果只寫「能幫使用者整理需求」，那一份 Word 模板也算。如果只寫「會問問題」，那 ChatGPT 也會問。要讓鼠勾以跟現有工具有區別，得有更具體的標準。

我在記事本最上面寫下四個詞：

手把手、低門檻、會挑戰、能落地。

然後一個一個展開，開始不斷地測試與迭代修正

1. 手把手

讓需求方PM 不用太煩惱思考「下一步要做什麼」。

實作上拆成幾件事：

• 一次只問一個問題（不是丟一張 20 題的問卷）
• 每題附 2-4 個選項範例（讓回答從「選一個」開始，不是從「想一個」）
• 答完每題自動進下一題
• 不確定時主動覆述與對標：「你的意思是 XX，對嗎？」

反例：你看過那種「點 1 開始 / 點 2 繼續 / 點 3 跳過」的命令列界面嗎？需求方PM 不會用那種東西。連我都不太想用。

我假設使用者不會主動引導自己/自己有想法，那就由工具引導。

2. 低門檻

零安裝、零學習、零 git。 （不過再好書推薦一次XD:為了你自己學git)
對需求方PM 來說，他願意打開的工具只有兩種：他平常就在用的，或「點連結就能用，簡單好上手的」。

ChatGPT 屬於前者。Custom GPT 屬於後者。

要使用者學 prompt engineering、學 markdown、學 git diff，太難了。

Custom GPT 這個低門檻看起來廢廢，但對我來說，是「使用者真的會用」跟「使用者打開一次就再也不打開」的差別。

3. 會挑戰

工具要會 push back，問問題，就像是那個很讚的 /grill-me。

這是鼠勾以跟通用 ChatGPT 最大的差別。通用 GPT 太想討好使用者（以及很會道歉）。一份「結構完整、內容空洞」的 PRD 比沒有 PRD 還危險，因為 SA 會被誤導到錯的方向去設計。

所以 我的規範設計中，Knowledge 裡有一份叫《挑戰檢查規則》的檔案，內容包含：

• 6 類觸發條件（範圍過大、目標模糊、跨區塊矛盾、關鍵遺漏、假設風險、資源衝突）
• 5 種跨區塊矛盾偵測（例如：目標說減少客服進線、但功能裡沒有自助查詢）
• 風險備註標記規則（使用者堅持原案時怎麼記）

實作上的調和：

• 語氣要溫和，先肯定再帶問題
• 一次最多挑戰一個點，不要連環追問
• 使用者堅持原案就尊重，記到風險備註，不再追

反例：跟通用 GPT 說「目標是降低客服進線，但不做自助查詢功能」，它會默默接受，然後幫你寫一份很漂亮的 PRD。鼠勾以會問：「那客服進線要靠什麼降？」

這條原則是整套工具最難實作的一條，後面會有專門幾天細講。

4. 能落地

需求方PM 寫完之後，產出物要能直接帶去找 SA。

具體包含：

• 結構化 PRD（目錄、章節、AC 都齊全）
• 端對端 Mermaid 流程圖（含畫面節點與錯誤分支）
• 畫面清單總覽（UI-01、UI-02……）
• 待確認清單（按業務/技術/設計分類）
• 個資風險評估
• 工時初估（含複雜度、角色拆分、Buffer）

為什麼是 Mermaid 而不是圖片？ 因為後續整條 SDLC 都會有 AI 參與：設計階段 AI 看流程圖補 user story、開發階段 AI 看流程圖出 scaffold、測試階段 AI 看流程圖生 test case。Mermaid 是文字、能被 AI 讀懂，圖檔嵌入 Word 給人看；原始碼留在附錄給 AI 接續用。

為什麼是 Word，不是 Markdown 或 HTML？

我也想用 Markdown，但需求方PM 普遍不會讀 Markdown，看到 ## ** 會疑惑（真的，沒騙你）

HTML 看起來最強，可是 token 用量高、嵌圖麻煩、對麻煩的是他想要小修改不會人工手動異動，或者備註。

Word 是最低門檻：每個人會打開、能改、能加註解、能寄。所以正式產出是 .docx；想要 Markdown 版的另外提供，當作補充選項。

在限制下，為什麼是 Custom GPT

四個原則寫完，回頭看可用的工具，答案其實就出來了。

Custom GPT 在四原則下的表現

優點：

• 手把手 + 低門檻：對話介面 + Knowledge 檔，幾乎是為這兩點打造的。沒有第二個工具能在「公司能用的 ChatGPT 帳號裡」直接做出來。
• 有挑戰：Instructions + Knowledge 可以塞下挑戰規則，雖然不如自架 LLM 精準，但夠用。
• 能落地：Code Interpreter 把 Mermaid 轉 JPG、用 python-docx 生 Word 檔。產出鏈完整。

缺點：

• 8000 字元的 Instructions 上限
• 不能呼叫公司內部 API：沒有 RAG，所有知識都得塞在 Knowledge 檔裡。
• Knowledge 上傳有大小限制：單檔上限、總數上限 (20份)，都得規劃。
• 沒有好的版本控制：改完直接上傳，他有個history但是不是很好看，只有顯示日期＆時間。
• 沒有 telemetry：使用者用得卡不卡、哪一題卡住、放棄率多少，全靠口頭回饋。Actions的地方原本想規劃，但內部政策不開放，最後採用問卷的方式

四原則沒有一個拿到 5 分，但每個都拿 3-4 分。在當下的資源條件下，這是務實的選擇。

給讀者：你手上的工具也可以

如果你想做類似的東西，但你公司不能用 Custom GPT，沒關係。四原則跟工具無關。

你可以這樣對應：

• 如果你有 Claude Projects：直接做，效果可能比 Custom GPT 更好（Knowledge 上限大、Artifacts 強）。
• 如果你有 Codex / Claude Code：寫一個 CLI 工具吃 markdown、吐 PRD；但要克服「需求方PM 不會用」這點
• 如果你公司禁用所有外部 AI：先用一份結構化的 Google Form 開始，把題庫設計清楚，光是這一步就能解 60% 的問題。剩下的 40%（挑戰、評分、產出 Word）等內部 LLM 上線再補。

工具是手段，不是目的。把四原則做出來，比追求最新最炫的工具有意義得多。我自己在做的過程裡，常常會被同事問「為什麼不用 OO」「為什麼不換 XX」，我都會回頭看一下這四個詞，然後說「現在這個夠用」。

小結

設計目標的存在意義，就是讓我在做每個小決定時，有一條線可以拉回來對。鼠勾以的這條線就是四個詞：手把手、低門檻、有挑戰、能落地。後續每一天的設計細節，幾乎都能拉回到這四個之一去解釋。

接下來我會把 Custom GPT 的構成攤開：Instructions、Knowledge、Conversation Starters，各自能做什麼、各自的限制是什麼。從架構面看，鼠勾以到底是個什麼形狀的東西。

這是 iThome 鐵人賽系列文章。明天見。